2.4.1-data-model-design

The domain model generates applications and data models through the "generate model" feature, with the data model entry accessible within the “App Mgt”.

Once the administrator enters the data model design page, entities (Forms) from the domain model will be displayed in the canvas area.
The data model design page is divided into four sections: the left side contains models and terminology, the top section is designated as the operation area, and the middle section is the canvas area. In this design area, users can configure forms, form field types, and the association relationships between forms.

2.4.1.1 Add Main Model

There are three types of main models: Regular form models, Category template models, and Simple category models, corresponding to the three types of forms.
To add a main model, drag it from the left side to the canvas area. Users can then fill in details such as the model name (which corresponds to the form name), the model code (corresponding to the form code), the type, the table name, and custom fields (form fields). When defining fields, users can specify field names, field codes, data types, lengths, and check the corresponding system fields.

The currently supported data types and their corresponding widgets are as follows:

Data type	Form Widgets
Text	Single-line Text
Long text	Multi-line Text
Bool	Toggle
Integer, Short Integer, Long Integer	Numeric
Single-precision floating-point, double-precision floating-point, high-precision floating-point	Numeric
Date, Date Time	Date
Time	Time
Enum (Single value), Enum (Multi-value)	Single-selection, Multi-selection
Directory Picker (Single Value), Directory Picker (Multi Value)	Directory Picker (Single Selection), Directory Picker (Multiple Selection)
External Key Association	External Key Association
Business Association	Business Association
Association Query	(No corresponding widget for data query display in lists and portals)
Target	(No corresponding widget, suitable for reverse generation of data models from forms, such as dynamic widgets or basic widgets)

2.4.1.2 Add Submodel

There are three types of submodels: Detail table model, Sub-detail table model, and Sub table model. When dragging a sub model into the canvas area, users must select a parent model. The sub model can also have custom fields. Once created, a connecting line will display the relationship between the sub model and the main model.

2.4.1.3 Add Reference Model

A reference model allows the addition of a data model from another application, reflecting the association between the current model and models from other applications. Reference models are displayed in gray and cannot be modified, they can only be viewed.

2.4.1.4 Reference Term Field

In addition to customizing model fields, the canvas area allows users to add existing terminology libraries. By dragging these fields directly into the model, users can quickly define model fields.

2.4.1.5 Model Form

After designing the data model, users can click "Design Apps" in the upper right corner of the canvas to enter "Form" list for form design. Conversely, the applied form can generate a data model in reverse.

To generate a form, click the "Form Design" in the middle. The form designer will also present a layout frame, which can be configured based on business needs. Fields from the data model will be converted into corresponding widgets and displayed in the form designer, where their properties can be configured on the right.
After generating the form, if changes are made to the fields in the data model, users can click the "Loading model" button in the form's data model to synchronize the updated fields. Conversely, if there are changes to the widget fields in the form design, clicking "Update Model" on the “Data Model” side will synchronize the changes back to the model.

For existing applications that require reverse data model generation, access the data model entry in the application and click "Auto Data Model Generating" to convert form widgets into a data model.

Note: Some form widgets, such as buttons, dividers, barcodes, QR Codes, text descriptions, image samples, timelines, and associated fields cannot be converted to the data model side. Other widgets will be converted into objects on the data model side, including images, attachments, videos, locations, regions, tags, dynamic widgets, basic widgets, main data, departments, and document editors.

2.4.1.6 External Key Association

A new type has been added to the data model, along with the addition of a form widget: foreign key association. This is primarily used to configure the association relationship between forms. For example, in a scenario involving an opportunity table and a customer table, different opportunities can be linked to different customers. The opportunity table utilizes a foreign key association to connect to the customer table.

Foreign key associations require configuration of field properties, including selecting the associated model and the type of association relationship. Supported associated models include main tables, detail tables, and sub-detail tables (but sub tables are not supported).
There are six association relationship types, divided into forward and reverse relationships.
Forward relationships: one-to-one, many-to-one, many-to-many;
Reverse relationships: reverse one-to-one, one-to-many, reverse many-to-many.
Forward relationships are presented as single-select (one-to-one, many-to-one) or multi-select (many-to-many) during runtime, while reverse relationships are only displayed for query purposes and cannot be selected. For details on configuration of foreign key association widgets, refer to Chapter 2.9.2.8.3 of Advanced Widgets.

Association	Description
One-to-One	e.g., "Employee" field in Account table: One account belongs to one employee, one employee has only one account.
Reverse One-to-One	Inverse of one-to-one. Relationship stored in the opposite table, e.g., "Linked Account" in Employee table: Calculated from the "Employee" field in Account table.
Many-to-One	e.g., "Primary Department" in Employee table: One employee has one primary department, but one department can have multiple employees.
One-to-Many	Inverse of many-to-one. Relationship stored in the opposite table. e.g., "Employees in Primary Department" in Department table: Calculated from "Primary Department" in Employee table.
Many-to-Many	e.g., "Assigned Positions" in Employee table: One employee can hold multiple positions, one position can be held by multiple employees. Requires an intermediate table for storage.
Reverse Many-to-Many	Inverse of many-to-many. Relationship stored in the opposite table. e.g., "Employees in Position" in Position table: Calculated from "Assigned Positions" in Employee table.